home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9610 / 000027_owner-urn-ietf _Wed Oct 9 22:17:01 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id WAA03937 for urn-ietf-out; Wed, 9 Oct 1996 22:17:01 -0400
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id WAA03932 for <urn-ietf@services.bunyip.com>; Wed, 9 Oct 1996 22:16:58 -0400
  3. Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA01697  (mail destined for urn-ietf@services.bunyip.com); Wed, 9 Oct 96 22:16:56 -0400
  5. Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <16731(4)>; Wed, 9 Oct 1996 19:16:54 PDT
  6. Received: by golden.parc.xerox.com id <2759>; Wed, 9 Oct 1996 19:16:47 PDT
  7. To: michaelm@internic.net
  8. Cc: rdaniel@acl.lanl.gov, urn-ietf@bunyip.com
  9. In-Reply-To: <325BB8BC.1248@internic.net> (message from Michael Mealling on
  10.     Wed, 9 Oct 1996 07:37:48 PDT)
  11. Subject: Re: [URN] advantages of NAPTR over PURLs
  12. From: Larry Masinter <masinter@parc.xerox.com>
  13. Message-Id: <96Oct9.191647pdt."2759"@golden.parc.xerox.com>
  14. Date: Wed, 9 Oct 1996 19:16:47 PDT
  15. Sender: owner-urn-ietf@services.bunyip.com
  16. Precedence: bulk
  17. Reply-To: Larry Masinter <masinter@parc.xerox.com>
  18. Errors-To: owner-urn-ietf@bunyip.com
  19.  
  20. > Do you see where you're going Larry? You are putting everything
  21. > we've already got in the URN framework and the NAPTR proposal
  22. > into PURLs. 
  23.  
  24. A new NAPTR DNS record type with protocol names & syntax that requires
  25. parsing and interpretation as a 'regular expression' isn't part of the
  26. PURL proposal. PURLs don't relegate the security issues to DNS
  27. security but rather rely on HTTP security.  PURLs don't require that
  28. application clients know anything about DNS other than 'Connect me to
  29. some machine that goes by this name'.
  30.  
  31. I think that _relying_ on parsing data out of DNS records is very
  32. fragile, and most of purported advantages for NAPTRs are mainly vapor.
  33.  
  34. > But you ARE changing the intent and current design of PURLS.
  35.  
  36. I think we read different papers about PURLs; the paper I read made it
  37. seem like it was intended as a low-cost implementation of URNs.
  38.  
  39. > If you can come up with a DISTRIBUTED database that has is as large
  40. > and as widespread as DNS that we can test the framework on then by all
  41. > means let us know cause we'll build the framework on that too.
  42.  
  43. I think this is misleading, since the NAPTR proposal doesn't
  44. distribute resolution services widely.
  45.  
  46. > If you've got a problem with NAPTR then you either have a problem
  47. > with the framework or DNS.
  48.  
  49. No, I have a problem with THAT particular USE of DNS.
  50.  
  51. Let me get down to the basics, though:
  52.  
  53. DNS updates are unreliable. DNS administration is a nightmare. The
  54. PURL proposal has worked out many of the issues of administration and
  55. security that are necessary for actual deployment of URNs, and the
  56. NAPTR proposal has only a wave at DNSSEC.
  57.  
  58. > I hope that won't be the case very soon. I'm building a
  59. > parallel registry in rwhois. It doesn't have the restrictions
  60. > that DNS does. Its more generalized and doesn't need to
  61. > be re-written everytime you add a field.
  62.  
  63. That's great! If you're building a parallel registry in rwhois, I hope
  64. that you address the administrative and update issues that were worked
  65. out in the PURL paper and that we can leave NAPTR behind.
  66.  
  67. Regards,
  68.  
  69. Larry
  70.